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Abstract 


This document describes the preferred design of a Pseudowire 
Emulation Edge-to-Edge (PWE3) Control Word to be used over an MPLS 
packet switched network, and the Pseudowire Associated Channel 
Header. The design of these fields is chosen so that an MPLS Label 
Switching Router performing MPLS payload inspection will not confuse 
a PWE3 payload with an IP payload. 


1. Introduction 


The standard MPLS encapsulations have no explicit protocol 
identifier. In order for a pseudowire (PW) [RFC3985] to operate 
correctly over an MPLS packet switched network (PSN) that performs 
MPLS payload inspection, a PW packet must not appear to a label 
switching router (LSR) as if it were an IP packet [BCP]. An example 
of an LSR that performs MPLS payload inspection is one that is 
performing equal-cost multiple-path load-balancing (ECMP) [RFC2992]. 
If ECMP were performed on PW packets, the packets in the PW may not 
all follow the same path through the PSN. This may result in 
misordered packet delivery to the egress PE. The inability to ensure 
that all packets belonging to a PW follow the same path may also 
prevent the PW Operations and Management (OAM) [VCCV] mechanism from 
correctly monitoring the PW. 
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This document specifies how the PW control word is used to 
distinguish a PW payload from an IP payload carried over an MPLS PSN. 
It then describes the preferred design of a PW Control Word to be use 
over an MPLS PSN, and the Pseudowire Associated Channel Header. 


1.1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


2. Avoiding ECMP 


A PW that is carried over an MPLS PSN that uses the contents of the 
MPLS payload to select the ECMP path may be subjected to packet 
misordering [BCP]. In cases where the application using the PW is 
sensitive to packet misordering, or where packet misordering will 
disrupt the operation of the PW, it is necessary to prevent the PW 
being subjected to ECMP. 


All IP packets [RFC791] [RFC2460] start with a version number that is 
checked by LSRs performing MPLS payload inspection. To prevent the 
incorrect processing of packets carried within a PW, PW packets 
carried over an MPLS PSN MUST NOT start with the value 4 (IPv4) or 
the value 6 (IPv6) in the first nibble [BCP], as those are assumed to 
carry normal IP payloads. 


This document defines a PW header and two general formats of that 
header. These two formats are the PW MPLS Control Word (PWMCW), 
which is used for data passing across the PW, and a PW Associated 
Channel Header (PWACH), which can be used for functions such as OAM. 


If the first nibble of a PW packet carried over an MPLS PSN has a 
value of 0, this indicates that the packet starts with a PWMCW. If 
the first nibble of a packet carried over an MPLS PSN has a value of 
1, it starts with a PWACH. The use of any other first nibble value 
for a PW packet carried over an MPLS PSN is deprecated. 


If a PW is sensitive to packet misordering and is being carried over 
an MPLS PSN that uses the contents of the MPLS payload to select the 
ECMP path, it MUST employ a mechanism that prevents packet 
misordering. A suitable mechanism is the PWMCW described in Section 
3 for data, and the PWACH described in Section 5 for channel- 
associated traffic. 


The PWMCW or the PWACH MUST immediately follow the bottom of the MPLS 
label stack. 
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3. Generic PW MPLS Control Word 
The Generic PW MPLS Control Word (PWMCW) is shown in Figure 1. 


0 1 2 3 
Qu, 2-354 BOF BP OF Od 2B A 6 Tg 996 Od 2 F 426. 789-20: 21 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

joo 0 O| Specified by PW Encapsulation 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 1: Generic PW MPLS Control Word 


The PW set-up protocol or configuration mechanism determines whether 
a PW uses a PWMCW. Bits 0..3 differ from the first four bits of an 
IP packet [BCP] and hence provide the necessary MPLS payload 
discrimination. 


When a PWMCW is used, it MUST adhere to the Generic format 
illustrated in Figure 1 above. To provide consistency between the 
designs of different types of PW, it SHOULD also use the following 
preferred format: 


0 É 2 3 
01234567890123456789012345678901 
toto tatHtata—ta tata tata tata tata ta tata ta ta tata tatatatatatatatat-t-t 

|o 0 0 o| Flags |FRG| Length | Sequence Number 
Fat o ta tata ta—ta tata tata tata tata ta tata tatatatatatatatatatatatat-t-t 


Figure 2: Preferred PW MPLS Control Word 


The meaning of the fields of the Preferred PW MPLS Control Word 
(Figure 2) is as follows: 


Flags (bits 4 to 7): 


These bits MAY be used by for per-payload signaling. Their 
semantics MUST be defined in the PW specification. 


FRG (bits 8 and 9): 


These bits are used when fragmenting a PW payload. Their use 
is described in [FRAG], which is currently a work in progress. 
When the PW is of a type that will never need payload 
fragmentation, these bits may be used as general purpose 
flags. 
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Length (bits 10 to 15): 


When the PSN path between the PEs includes an Ethernet 
segment, the PW packet arriving at the CE-bound PE from the 
PSN may include padding appended by the Ethernet Data Link 
Layer. The CE-bound PE uses the length field to determine 
the size of the padding added by the PSN, and hence extract 
the PW payload from the PW packet. 


If the MPLS payload is less than 64 bytes, the length field 
MUST be set to the length of the PW payload plus the length 
of the PWMCW. Otherwise it MUST be set to zero. 


Sequence number (Bit 16 to 31): 


The sequence number implements the sequencing function 


[RFC3985]. The use of this field is described in Section 4. 
4. Sequencing 
The sequence number mechanism is PW specific. The PW encapsulation 


specification MAY define a sequence number mechanism to be used, or 
it may indicate that the mechanism described here is to be used. A 
pseudo-code description of this mechanism is given in the non- 
normative Appendix. 


The sequence number mechanism described here uses a circular unsigned 
16-bit number space that excludes the value zero. 


4.1. Setting the Sequence Number 


For a given PW, and a pair of routers PE1 and PE2, if PE1 supports 
packet sequencing and packet sequencing is enabled for the PW, then 
the following procedures MUST be used: 


o The initial packet transmitted on the PW MUST be sent with 
sequence number one. 


o Subsequent packets MUST increment the sequence number by one for 
each packet. 


o The sequence number that follows 65535 (maximum unsigned 16-bit 
number) is one. 


If the transmitting router PE1 does not support sequence number 
processing, or packet sequencing is disabled, then the sequence 
number field in the control word MUST be set to zero for all packets 
transmitted on the PW. 
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4.2. Processing the Sequence Number 


If a router PE2 supports receive sequence number processing, and 
packet sequencing is enabled for this PW, then the following 
procedure is used: 


When a PW is initially set up, the "expected sequence number" 
associated with it MUST be initialized to one. 


When a packet is received on that PW, the sequence number SHOULD be 
processed as follows: 


o If the sequence number on the packet is zero, the sequence 
integrity of the packets cannot be determined. In this case, the 
received packet is considered to be in order. 


o Otherwise if the packet sequence number equals the expected 
sequence number, the packet is in order. 


o Otherwise if the packet sequence number is greater than the 
expected sequence number, and the packet sequence number minus 
the expected sequence number is less than 32768, the packet is 
within the allowed receive sequence number window. The 
implementation MAY treat the packet as in order. 


o Otherwise if the packet sequence number is less than the expected 
sequence number and the expected sequence number minus the packet 
sequence number is greater than or equal to 32768, the packet is 
within the allowed receive sequence number window. The 
implementation MAY treat the packet as in order. 


o Otherwise the packet is out of order. 


If the packet is found to be in order, it MAY be delivered 
immediately. 


If the packet sequence number was not zero, then the expected 
sequence number is set to the packet sequence number plus one. The 
expected sequence number that follows 65535 (maximum unsigned 16-bit 
number) is one. 


Packets that are received out of order MAY either be dropped or 
reordered. The choice between dropping or reordering an out-of- 
sequence packet is at the discretion of the receiver. 


If a PE negotiated not to use receive sequence number processing, and 
it received a non-zero sequence number, then it SHOULD send a PW 
status message indicating a receive fault, and disable the PW. 
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5. PW Associated Channel 


For some PW features, an associated channel is required. An 
associated channel is a channel that is multiplexed in the PW with 
user traffic, and thus follows the same path through the PSN as user 
traffic. Note that the use of the term "channel" is not a "PW 
channel type" as used in subsection 5.1.2 of [RFC3985]. 


When MPLS is used as the PSN, the PW Associated Channel (PWAC) is 
identified by the following header: 


0 1 2 3 

Qed 2.3) 43 62778-90012 BA OO Tgog Ode 238 24 6 B90 Oo 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|o 0 0 1|Version| Reserved | Channel Type 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 3: PW Associated Channel Header 


The meanings of the fields in the PW Associated Channel Header 
(PWACH) (Figure 3) are: 


Version: 


This is the version number of the PWACH. This specification 
defines version 0. 


Reserved: 
MUST be sent as 0, and ignored on reception. 


Channel Type: 


The PW Associated Channel Type is defined in the IANA PW 
Associated Channel Type registry [IANA]. 


Bits 0..3 MUST be 0001. This allows the packet to be distinguished 
from an IP packet [BCP] and from a PW data packet. 


6. IANA Considerations 


IANA has set up a registry of "Pseudowire Associated Channel Types". 
These are 16-bit values. Registry entries are assigned by using the 
"IETF Consensus" policy defined in [RFC2434]. The value 0x21 
indicates that the Associated Channel carries an IPv4 packet. The 
value 0x57 indicates that the Associated Channel carries an IPv6 
packet. 
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7. 


Security Considerations 


An application using a PW Associated Channel must be aware that the 
channel can potentially be misused. Any application using the 
Associated Channel MUST therefore fully consider the resultant 
security issues, and provide mechanisms to prevent an attacker from 
using this as a mechanism to disrupt the operation of the PW or the 
PE, and to stop this channel from being used as a conduit to deliver 
packets elsewhere. The selection of a suitable security mechanism 
for an application using a PW Associated Channel is outside the scope 
of this document. 


If a PW has been configured to operate without a CW, the PW 
Associated Channel Type mechanism described in the document MUST NOT 
be used. This is to prevent user payloads being fabricated in such a 
way that they mimic the PW Associated Channel Header, and thereby 
provide a method of attacking the application that is using the 
Associated Channel. 
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Appendix. Sequence Number Processing 
This appendix is non-normative. 


This appendix provides a pseudo-code description of the sequence 
number processing mechanism described in Section 4.2. 


unsigned16 RECEIVED /* packet sequence number 

unsigned16 EXPECTED = 1 /* expected sequence number 
/* initialized to one 

boolean sequencingDisabled 

boolean dropOutOfOrder /* policy on in-window out of sequence 
/* packets 


updateExpected () 
begin 
EXPECTED := RECEIVED + 1; 
/* Because EXPECTED is an unsigned1l6 it will wrap 
/* from 65535 to 0 
/* zero is skipped 
if (EXPECTED = 0) 
EXPECTED := 1; 
return; 
end; 


On receipt of a PW packet from PSN: 


begin 
if (RECEIVED = 0) then begin 
processPacket (); 
return; 
end; 


if (sequencingDisabled) then begin 
/* A packet was received with non-zero sequence number, but 
/* sequencing is disabled 
indicateReceiveFault (); 
disablePW(); 
return; 
end; 


/* The received sequence is the expected sequence number 
if ((RECEIVED = EXPECTED) then begin 

/* packet is in order 

processPacket (); 

updateExpected(); 

return; 
end; 
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/* Test for received sequence number is greater than 
/* the expected sequence number and is within the 
/* allowed receive sequence number window 
if ((RECEIVED > EXPECTED) and 
( (RECEIVED - EXPECTED) < 32768) then begin 
/* packet is in the window, but there are late/missing 
/* packets 
if (dropOutOfOrder) then begin 
/* policy is to receive immediately, dropping 
/* out of sequence packets 
processPacket (); 
updateExpected(); 
return; 
end else begin 
/* policy is to wait for late packets 
processMissingPackets (); 
return; 


end; 
end; 


/* Test for the received sequence is less than the 

/* expected sequence number and is within the allowed 

/* receive sequence number window 

if ((RECEIVED < EXPECTED) and 
( (EXPECTED - RECEIVED) >= 32768) then begin 
/* packet is in the window, but there are late/missing 
/* packets 


if (dropOutOfOrder) then begin 
/* policy is to receive immediately, dropping 
/* out of sequence packets 
processPacket (); 
updateExpected(); 
return; 

end else begin 
/* policy is to wait for late packets 
processMissingPackets()j; 
return; 

end; 

end; 


/* Received packet was outside the allowed receive 
/* sequence number window 
processOutOfWindow ();}; 

end; 
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